1. Technical Field
The present invention relates to the field of device driver technology and, more particularly, to a driving method used in handheld devices.
2. Description of the Related Art
With the development of various hardware components and peripherals used in handheld devices (such as mobile phones, portable game consoles, portable computers, personal multimedia devices, etc.), more and more functions can be performed by means of these hardware components and peripherals. For example, multi-mode touch screens, real-time video, and GPS capabilities are all relatively new components and peripherals found in portable handheld devices.
In some cases, a “component” is embedded in the handheld system itself and is distinguishable from a “peripheral,” which may be incorporated into the system but is not necessarily an integral part of the device's primary function. Typically, a “module” can be either a component or a peripheral. Nevertheless, the terms “component,” “peripheral,” and “module” are often used interchangeably and share enough commonality that their use herein is interchangeable. One common feature of components, peripherals, modules, and many other electronic hardware elements is the need for a device driver.
As is well known, device drivers are usually custom-designed in software to expose the controllable features of the underlying hardware for which they were designed. The device driver exposes a common application programming interface (API) known to higher layers of software, often as various sets of data structures and software function calls. When the higher layers of software load or otherwise manipulate the data structures, or when the higher layers of software make software function calls, the device driver translates the requests of the higher layers of software into instructions to the underlying hardware. Accordingly, since many manufacturers may make many pieces of hardware capable of performing the same or a similar function, different, customized device drivers are needed for each of the different hardware pieces.
In fixed computer installations, in a conventional personal computer (PC) for example, some software makers have begun to provide a unified device driver architecture for a 3D graphics implementation. In such implementations, a graphics “card” is installed on a PC motherboard; often in a standardized peripheral component interconnect (PCI) port or a standardized accelerated graphics port (AGP). PC implementations are well suited to a unified device driver architecture because of the high degree of standardization of computer hardware and operating system software.
FIG. 1 illustrates a hardware/software block diagram representing how a unified driver architecture may be implemented for various hardware graphics processing units (GPU's) and their associated software drivers.
In FIG. 1, a timeline 102 shows the progression of weeks, months, or years. A driver roadmap 104 shows various releases of software drivers and a GPU roadmap 106 shows various releases of hardware. At a first point on the timeline 102, a first GPU core 110 is released at the same time as a corresponding first software driver 108. The first software driver 108 has a unified driver applications programming interface (API) 112 that is compatible with a corresponding unified driver hardware abstraction layer (HAL) 114. As time passes, graphics card makers release additional software drivers 116, 124 having a unified driver API 118, 126 respectively. At the same time, at overlapping times, or at different times, graphics card makers release additional GPU cores 120, 128, each having a corresponding HAL 122, 130.
As illustrated by compatibility arrows in FIG. 1, the substantial overlap in the unified driver software APIs and unified driver HALs permit many versions of software drivers to work cooperatively with many versions of GPUs. That is, the HALs and APIs of the various hardware and software releases permit complete backward compatibility and sometimes forward compatibility. The first software driver 108 is compatible with a first GPU core 110. A second software driver 116 release is compatible with first GPU core 110 and also with a second GPU core 122, which may not even be available when the second software driver 116 becomes available. A third software driver 124 release is compatible with all of the hardware GPU cores 114, 122, 130 that have been made previously.
The first unified software driver 108 has forward compatibility with the next HAL 120, but not with the subsequent HAL 128 release. That is, forward compatibility is desirable, but not guaranteed and may be limited to one or even no future HALs.
Architectural standardization of both system software hardware interfaces permits the unified driver applications of PC 3D graphics implementations. As shown in FIG. 1, system software 132, e.g., operating systems, provide a common architecture onto which software drivers can be designed. It is very common for the operating system and application layer software to determine the functionality provided by a software driver. Thus, the functionality of the driver is integrated throughout the driver.
Similarly, well-accepted hardware interfaces are present in PC architecture such that GPU designs in PCs are often substantially similar to each other. On one side of the GPU, interfaces such as hardware interface 134 have been formally or informally standardized and so are common to all GPU's. On the other side of each GPU, a substantially common HAL can be designed to work cooperatively with the unified driver software layer of the software driver. That is, since there is substantial commonality of features between software drivers that is guided by system software 132, there is also substantial commonality of the software driver API layer to the unified driver HAL layer interface.